1. Field of the Invention
The present invention relates to a logic checking method for checking operation of circuit which is to be connected to bus in System LSI or the like.
2. Description of the Related Art
Hitherto, checking of logic during development of System LSI which has an integrated CPU is conducted using actual logic circuit by performing simulation using software which runs on an actual machine.
First, a prior art logic checking method is described with an example in which an arbiter is an object to be checked. When a plurality of bus master circuits connected to a certain bus try to access to one or more bus slave circuit or circuits, one of them must first obtain priority of accessibility to avoid collision of signals from different bus masters over the bus.
An arbiter is a circuit of which function is to arbitrate the accessibility. In the prior art checking of an arbiter is conducted by actually connecting logic circuits which are used as bus masters.
FIG. 20 shows a prior art checking method of an arbiter in which Master A 220, Master B 221 and Master C 222 are blocks to operate as masters on bus 240. Slave D 230 is a block to operate as a slave on bus 240. Only single slave is connected to the bus 240 in this example but more than one slave may be connected. The Arbiter 210 is a block to perform arbitration of the accessibility to bus 240. This Arbiter 210 is an object of logic checking.
A master block first requests the Arbiter 210 to give accessibility priority to the bus 240 to avoid collision with other masters when it tries to gain access to a slave block (to transmit data or to request data). The Arbiter 210 arbitrates requests for bus accessibility from masters to issue bus access permission signals to a master. A master block can gain access to a Slave D 230 via bus 240 only after it obtained this permission signals.
As shown in the example of FIG. 20, there may be various kinds of bus masters with various functionality, such as, for example, a Master A 220 which receives data via bus 250 which is a different path from the bus 240 to transmit them to the Slave D 230 after given processing, or a Master B 221 which has an additional functionality for requesting data to the Slave D 230 to output obtained data via the bus 251 after given processing besides the similar functionality with Master A 220, or a Master C 222 which has no other interface than the bus 240 for data reception and transmission and requests data to the Slave D 230 for returning obtained data to the Slave D 230 after given processing.
FIG. 21 shows the way how arbitration is conducted. In this case, the order of priority of bus accessibility to be issued by the function of the Arbiter 210 between the Master A 220, the Master B 221 and the Master C 222 is set as “Master A>Master B 221>Master C”. Also, in this example, any of the bus masters conducts only data transmission to the Slave D 230 but makes no request for data to it. The burst length of data transmission is fixed at 4 bursts.
In FIG. 21 the Master A 220 issues a request for bus accessibility req a at timing a and the Arbiter 210 returns an acknowledgement signals ack a at timing b. Receiving this, the Master A 220 starts data transmission at timing c. During the same period, the Master B 221 issues a request for bus accessibility req b at timing c and the Master C 222 req c at timing d, respectively, but it is shown that they are kept waiting.
When data transmission of the Master A 220 is over, the Arbiter 210 returns acknowledgement signals ack b to Master B 221 at timing g. At timing g requests for bus accessibility for Master B 221 and Master C 221 compete but since a higher priority is given to Master B 221, an acknowledgement is given to Master B 221. In this way the Arbiter 210 arbitrates bus accessibility to prevent collision over the bus 240. Bus 240 in FIG. 21 shows this.
In such bus arbitration, if only such a case is considered as Master A 220 and Master B 221 are in competition, for example, test items to be checked on bus arbitration circuit are those events where; (1) only req a is issued, (2) only req b is issued, (3) both req a and req b are issued, with req a issued earlier, (4) both req a and req b are issued, with req b issued earlier, (5) both req a and req b are issued simultaneously, (6) both req a and req b are simultaneously issued, while currently Master A 220 is receiving acknowledgement signals ack a, and (7) both req a and req b are simultaneously issued, while currently Master B 221 is receiving acknowledgement signals ack b. To check logic of the arbiter circuit, it is required to cause all of the above events occur but, for example, even if it is desired to cause “(5) both req a and req b are issued simultaneously”, Master A 220 and Master B 221 which are actual circuitries can issue request signals only after a given processing, so that it is impossible to control timing of issuance of a bus access request at will. Accordingly, it is necessary to keep two masters executing transactions for issuing a bus access request until simultaneous output of requests for access is achieved by both masters.
The more number of bus master circuits is, the more complex their combination becomes, thus increasing the number of test items. As a result it would take very long simulation time to perform tests of all the test items necessitating a large number of test statements.
Further, as for the timing of start of checking, checking of an arbiter can be conducted only after completion of each of bus master circuits (completion of checking). If checking of an arbiter is conducted using a bus master circuit of which checking is not completed and any failure develops, it would be difficult to specify whether the cause of the failure lies in the bus master circuits or in the arbiter, resulting in a long checking period.
Next, described is logic checking for such circuits as memory controllers, I/O interfaces and bus bridges. FIG. 22 shows a prior art test bench consisting of actual circuits only. As shown here, a test is conducted using such circuitries as CPU and DMA (Direct Memory Access) controller which are actually connected to an object to be checked. FIG. 23 shows an example of statements of a prior art test sequence for logic checking. Main flow of the test code is described as follows.
1. (step 1.1) initialize checking the test bench as a whole, 2. (step 1.2) initialize the actual circuits which are connected to the object to be checked, 3. (step 1.3) initialize the object to be checked, 4. (step 1.4) setting for data transmission the actual circuits connected to the object to be checked, 5. (step 1.5) activate data transmission of the actual circuits connected to the object to be checked, 6. (step 1.6) finalize the actual circuits connected to the object to be checked after data transmission is completed, 7. (step 1.7) finalize the object to be checked, and 8. (step 1.8) finalize the test bench as a whole.
In the above steps 1 and 2 included are such processes as fetching from memory of a program to be processed in the CPU and initialization of DMA. Steps 2, 4, 5 and 6 are the processes required for operation of the actual circuits connected to the object to be checked. The larger the scale of an LSI is, the more complex these processes tends to become and those processes become overheads at a time of a simulation, when the object to be checked is being checked. If some malfunction develops in the related portion resulting in a failure of achieving a desired performance, testing of the object to be checked would be made difficult. Also, in case of DMA, it would be difficult to test the object to be checked under a situation in which all modes of data transmission specified by the bus are caused to take place. Also, selection of addresses required in data transmission at will or arrangement of such addresses in desired order would be difficult to conduct only by setting of DMA.
FIG. 24 is a block diagram showing an object of a simulation in a prior art. A bus bridge 2 connects various buses within circuit to control data transmission between buses. A memory 3 is a storage device. A memory controller 4 controls write/read operations into or out of the memory 3. An IO-bus 5 provides a data path for data transmission within the circuit between various input/output devices or machines. Each of IO1 interface 6, IO2 interface 7 and IO3 interface 8, respectively controls data transmission to and from I/O devices connected to this circuit. A device bus 11 is a data path for data transmission between logic circuits within the circuit. A device (1) 12 and a device (2) 13 have logic function such as compression and/or expansion, respectively. A CPU 20 controls the circuit as a whole. A ROM 21 stores programs etc.
The prior art example described in FIG. 24 is solely comprised of functions used in actual circuit. A CPU 20 executes programs retrieved from the ROM 21, for example, to transfer the resulting contents to the memory 3 and then executes instructions read out of memory 3. In this case the instruction read out of memory 3 decides what to be executed next by CPU 20, so that instruction fetching necessarily takes place before any transmission of data, except that an instruction is held in a cache within the CPU 20.
As described above, checking of a logic circuit requires a simulation to be conducted by preparing actual software statements to produce a ROM image. However, it is not easy to make statements in actual software to produce stimuli for achieving checking of a desired functional block and requirement of initialization of various components such as a CPU makes it difficult to conduct a checking simply. Furthermore, if a CPU is actually used in a simulation, execution will be very time-consuming. What will take only about 10 seconds in an actual machine would sometimes take 24 hours for a run in a simulation.
In the prior art example given in FIG. 24 starting data transmission from other devices than the CPU 20 would require activation of DMA by setting IO1 interface 6 etc. In this case different setting methods must be applied to each I/O and transfer rate is decided depending on what kind of I/O device is used.
Accordingly, in addition to complex setting processes themselves, only limited number of transfer modes is available. This makes it impossible to achieve consecutive transmission to take place, thus complex situation under which various cases occur can not be created. As a result complete checking is difficult to be performed.